More bits for DWN, which published some of the previous ones last week. A release update was posted by Andreas Barth. Items discussed include the full freeze of Etch (delayed slightly), the kernel firmware issue (considered resolved by the release team), an analysis of remaining release critical bugs, and some final changes to the release policy including LSB 3.1. All developers should read the full email for details. Work continues on d-i RC1. Everything is in place and only some building and testing needs to be done before the new version of the installer is released. Development work on etch's installer after this will be limited to bug fixes, and an update to the 2.6.18 kernel. Frans Pop posted a todo list and an updated timeline. ARM v3 support. There was a thread on debian-arm about whether etch should support the arm v3 instruction set, used in a few older arm systems, but not supported by mono. Wookey said "Yes. I think the time has come for arm to drop v3. It might have been better to anounce this earlier, but never mind." There were no objections.

Way back at Steve's Debian BBQ I had a late night conversation with Wookey about the fun I'd had hacking on the E3 and how gradually getting more bits into the linux-omap or mainline kernel gave me a bit of a kick. And he talked about the Balloon and how someone who would do that for it would be quite useful. I, of course, foolishly volunteered if presented with suitable hardware. The next day came and I thought no more of it until the following weekend when I got handed a board. Ooops. I got stuck for a long while fighting with the major NAND changes in 2.6.18, but thanks to Vitaly Wool's YAFFS cleanups eventually got a board that would boot and mount the rootfs. This allowed me to start looking at drivers. Today I finally got USB host working. In addition I have the CF slot working (and have had networking going with my CF network card [which doesn't bloody get detected if the dongle isn't inserted. Grrrr.]). As far as I'm concerned that's significant progress (even if it's largely been as a result of being able to use Nick Bane's existing work). The main item left to get working on my board is USB client (sa11x0-udc), so that's my next task. I have a driver but unfortunately it doesn't seem to want to work. I shall kick it. I've also got LED and I2C drivers to write, but they should be a doddle.

Being around other geeks is bad, sometimes. Over the weekend I went to the UKUUG Linux conference along with a fair number of the other UK Debian gang. I had a great time, although the conference clashed with the football so I missed some talks. I also saw Wookey and Luke using their TomTom sat-nav units. I couldn't resist the temptation for long, and I've just ordered one for myself too. The 510 looks like a good choice - small, runs Linux, and is apparently compatible with OpenTom.

X Window security. Wandered outside the hack lab to sip a drink and cool down. There I saw Keith Packard and Bdale Garbee. Quickly introduced myself to them both, then asked Keith what his take was on the recent OpenBSD complaints that X11 is insecure by design [1] [2]. Keith said he wasn't going to respond to those complaints, because DRI/DRM already provides what Theo de Raadt says he wants in the way of kernel control over dma and register access on video cards. Many X11 video drivers are not yet converted over to doing things the DRI/DRM way, and so Theo is correct that X11 has huge security holes. But they are not permanent; the future is already arriving. Although DRI/DRM is positioned as a 3d technology, it is intended that even 2d drivers in the future will conform themselves to its API. Keith also said that OpenBSD's representative on the X11 team is easy to work with and cooperates well with the team, so there is hope that if OpenBSD turns its attention to X11 support, everyone will soon benefit from the comprehensive security audit. Although the DRI/DRM design solves the security problems, it is a bitch to implement. Mode switching alone is so finicky and is so tied into both the video hardware and x11 server optimizations, that it has never successfully been implemented in the kernel. Keith said he supported the idea of isolating the mode switching code out into a small, privilege separated userland utility. There were many other things said, which sounded positive, but without the aid of a tape recorder, I can't remember them. Putting packages out of main. Learnt a trick today, courtesy of Phil Hands and Ralph Amissah. If you want to upload a package into a part of the distribution other than main, you alter the Section: field of the debian/control file in your package. Suppose your package fits into the text section, because you use it to process text. Maybe you reimplemented awk. If you put Section: text the package will go into the text portion of the main repository. If your version of awk depends on a library that is in the non-free section, you would put it in the contrib section. So you would put this in your debian/control file: Section: contrib/text and Bob's your uncle. Politics. I find myself doing vastly more politics at this conference than coding, although I am getting some of that done too. When people are deep inside their own worlds, it takes a lot of work to bridge between the worlds. So far it seems like time well invested. Embedded. If anyone needs any embedded work done, Wookey is your guy. Send him an email with a proposal.

1. 2006-05-11 22:00:04 Re: security bug in x86 hardware (thanks to X WIndows)
2. 2006-05-13 20:07:35 Re: security bug in x86 hardware (thanks to X WIndows)

scratchbox 2, crossbuild.